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ABSTRACT 

It  has  long  been  reasoned  that  there  is  an  inherent  interdependence  between 
some  production  tasks,  and  that  this  can  influence  how  production  should  be 
organized  for  efficiency.  Tlius,  it  has  been  shown  diat  the  close  integration  of 
steel-making  and  steel  rolling  can  reduce  the  costs  of  steel  production  by  reducing 
the  need  for  reheating  materials  in  process. 

Specialists  in  engineering  design  have  shown  that  tliere  is  also  an  important 
form  of  interdependence  between  elements  in  engineering  design  tasks  - 
interdependence  with  respect  to  problem-solving.  In  this  paper,  I  generalize  and 
build  upon  this  observation  to  point  out  that  problem-solving  interdependence  is  an 
important  but  currently  unexplored  aspect  of  many  or  most  innovation  tasks  ranging 
from  the  design-build  interface  to  the  marketing-R&D  interface. 

Problem-solving  interdependence  can  vary  as  a  function  of  how  tasks  are 
specified  or  "partitioned"  in  a  given  innovation  project.  I  propose  that  understanding 
and  managing  task  partitioning  can  increase  the  efficiency  and  effectiveness  of 
innovation  project  work.  I  suggest  that  potential  high  task  interdependence  with 
respect  to  problem-solving  can  be  predicted  in  many  projects,  and  can  then  be 
managed  (1)  by  changing  the  boundaries  of  affected  tasks,  and/or  (2)  by  taking  steps 
to  improve  problem-solving  communication  among  affected  tasks.  Finally,  I  note 
the  potential  value  of  tlie  innovation  task  partitioning  concept  to  a  number  of  areas  of 
innovation  process  research,  and  offer  some  suggestions  for  further  work. 


1     I  am  indebted  to  Anne  Carter,  Professor  of  Economics,  Brandeis 

University,  and  to  Dietmar  Harhoff,  PhD  Candidate  at  the  MIT  Sloan  School 
of  Management,   for  their  thoughtful  critiques  of  this  paper. 


1.0:  Dividing  An  Innovation  Project  Into  Tasks 

An  innovation  project  of  any  magnitude  is  divided  up  ("partitioned")  into  a 
number  of  tasks  and  subtasks  that  may  then  be  distributed  among  a  number  of 
individuals,  and  perhaps  among  a  number  of  firms.  When  the  partitioning  process  is 
complete,  the  component  tasks  and  their  interfaces  are  specified  -  implicitly  or 
explicitly  -  so  that  all  will  fit  and  work  together  to  form  the  total  project  when 
combined.  Such  specifications  say  in  effect:  "TTiis  is  the  nature  of  Task  X.  TTiese 
are  the  inputs  it  will  or  can  receive  from  other  parts  of  the  project;  and  these  are  the 
outputs  it  must  provide  to  specified  points  in  the  project  at  specified  times."  Note 
that  this  partitioning  process  focuses  on  the  innovation  work  itself,  and  not  on  the 
product  or  process  resulting  from  that  work.  For  example  a  new  product  may 
physically  consist  of  components  A  and  B.  But  the  innovation  project  tasks  leading 
to  tlie  development  of  that  product  may  ha\'e  been  partitioned  according  to  different 
boundaries,  and  it  is  the  latter  we  are  concerned  witli  here. 

Small  innovation  projects  may  be  partitioned  into  tens  or  hundreds  of 
component  tasks.  Large  projects  may  be  divided  into  thousands  or  even  tens  of 
thousands  of  such  tasks,  woven  into  an  intricate  network  of  interrelationships. 


Figure  1 :  Schematic  of  Simple  Project  Task  Network 


Figure  1  shows  a  simple  project  task  network  in  schematic  form.  Here,  tasks 
(or  groups  of  tasks)  are  shown  as  circles  or  nodes,  and  interconnecting  lines  show 
the  nature  of  task  interdependencies  -  that  is,  show  that  the  outputs  of  some  tasks  are 
required  as  the  inputs  of  others. 

Task  networks  can  be  drawn  at  a  number  of  levels  of  aggregation  depending 
on  one's  purpose.  For  example,  if  one  is  planning  to  manage  the  start-up  of  an 
entire  auto  company,  "develop  car  model  X"  may  well  be  shown  as  a  single  activity 
in  a  complex  task  network.  But  managers  responsible  for  that  project  only  might 
well  devote  an  entire  network  to  related  tasks  -  perhaps  to  the  level  of  detail  of 
"develop  front  left  door  of  car  model  X".  Then,  those  in  charge  of  door 
development  work  might  in  tum  develop  a  network  consisting  of  tasks  at  the  level  of 
"develop  door  locking  mechanism",  and  so  forth. 

There  are  many  different  ways  to  partition  a  given  project.  Thus,  in  tlie 
instance  of  the  "develop  car  model  X"  activity  mentioned  above,  project  participants 
might  decide  to  specify  "develop  left  front  door"  as  a  task,  or  they  might  decide  to 
specify  "develop  left  side  of  car"  as  a  task  and  then  specify  subsidiary  tasks  such  as 
"develop  windows";  "develop  door  locks";  etc.,  in  a  way  that  never  isolates 
development  of  the  door  itself  as  a  separate  task.  The  actual  partitions  chosen  in  a 
given  project  are  at  the  discretion  of  project  managers  and  participants. 


2.0:  Task  Changes.  Problem-Solving  Interdependence  and  Efficiency 

Project  managers  specify  tasks  and  their  interrelationships  so  tliat  they  can 
distribute  innovation  effort  across  people  and  organizations,  both  in  parallel  and  in 
series  with  respect  to  time.  It  is  the  assumption  that  task  boundary  (input  and 
output)  specifications  will  be  relatively  stable  as  a  project  proceeds  that  allows 
project  participants  to  focus  on  their  own  tasks,  with  some  assurance  that  their 


output  will  properly  mesh  with  the  output  of  others  to  comprise  the  total  intended 
project  output. 

Yet  changes  to  initially-established  task  specifications  and  interrelationships 
are  often  required  during  the  course  of  a  project  because  planning  errors  were  made, 
or  because  new  information  is  introduced  that  was  not  available  at  that  project's  start. 
In  the  instance  of  innovation  projects,  changes  for  the  latter  reason  are  especially 
likely,  because  the  core  function  of  many  innovation  project  tasks  is  precisely 
problem-solving  and  the  generation  of  new  information. 

Changes  caused  by  a  single  new  infomiation  "event"  may  be  restricted  to  only 
one  task,  or  may  affect  the  task  network  more  widely.  For  example,  suppose  that  a 
task  in  an  auto  development  project  involves  research  directed  towards  developing  a 
very  fuel-efficient  engine.  And  suppose  that  research  reveals  that  the 
originally-planned  approach  to  that  problem  will  not  succeed.  Then,  one  might 
devise  a  new  approach  to  achieving  that  same  goal,  in  which  case  no  other  task  need 
be  affected  by  the  new  information.  Or,  one  might  decide  that  one  will  change  other 
tasks  or  their  interrelationships  to  compensate  for  the  shortfall  and  maintain  overall 
project  performance.  (For  example,  one  might  decide  to  try  and  lower  friction  in  the 
drive  train,  and/or  try  to  decrease  the  weight  of  the  car  to  meet  the  original  goal  for 
fuel  efficiency.)  In  this  latter  case  the  response  of  project  participants  to  the  new 
information  clearly  involves  more  extensive  changes  in  the  original  task  network. 

With  tliis  example  in  mind,  let  me  define  the  interdependence  between  any 
two  innovation  project  tasks  with  respect  to  problem-solving  as  the  likelihood  tliat 
efforts  to  perform  one  of  the  tasks  to  specification  are  likely  to  spill  over  and  require 
coordinated  problem-solving  in  the  other.  The  higher  this  probability  in  a  given 
instance,  the  greater  the  problem-solving  interdependence. 

Changes  introduced  to  task  specifications  after  project  work  is  underway  can 
be  costly  because  they  often  make  work  already  done  valueless,  and/or  may  degrade 
the  solution  ultimately  arrived  at,  as  task  work  groups  strive  to  "save"  work  already 


done  by  making  suboptimal  adaptations  to  change. 

I  propose  that  the  cost  of  such  changes  will  be  less,  other  things  being  equal, 
if  task  boundaries  are  arranged  to  reduce  the  problem-solving  interdependence 
among  project  tasks.  (Note  that  such  partitioning  changes  will  not  necessarily  reduce  • 
or  increase  -  the  amount  of  problem-solving  required  in  a  given  innovation  project. 
They  simply  affect  how  that  problem-solving  is  distributed  among  tasks.) 

The  rationale  behind  this  proposal  is  simply  that  problem-solving  involves 
communication  and  coordination  among  problem-solvers.    It  seems  reasonable  that 
any  bamers,  such  as  task  boundaries,  placed  between  such  problem-solvers  will 
add  to  the  cost  of  their  efforts.    Empirical  research  by  AUen  offers  some  preliminary 
support  for  this  idea.  Among  the  barriers  commonly  put  into  place  between 
personnel  engaged  in  different  tasks  are  physical  distance  and  formal  organizational 
barriers  (e.g.,  membership  in  different  groups).    Allen  has  empirically  examined  the 
effect  of  both  of  these  barrier  types  and  has  found  that  members  of  R&D  laboratories 
separated  by  either  communicate  far  less  frequently  than  do  members  not  so 
separated.(l) 

Additional  support  comes  from  earlier  work  by  researchers  studying 
engineering  and  architectural  design  -  one  type  of  innovation  project  task.    Some 
studying  in  these  fields  have  found  it  reasonable  to  argue  that  the  interdependence  of 
elements  in  a  design  problem  differ,  and  that  elements  having  a  higher 
interdependence  will  be  harder  to  "solve".  Thus  Alexander  (2)  (who  may  have  been 
the  pioneer  in  this  line  of  argument)  has  suggested  that  incremental  adjustments  over 
time  to  products  with  a  traditional  design  (for  example,  a  house  design  that  is 
traditional  in  a  particular  society)  has,  via  an  unconscious  process,  resulted  in 
product  designs  with  subsystems  that  can  be  adjusted  relatively  independently.  He 
then  argued  that  modem  designers  must  strive  to  create  such  subsystem 
independence  in  the  projects  they  are  working  on,  lest  the  design  problems  they  face 
become  so  complex  as  to  be  insoluble.    With  Manlieim,  Alexander  also  devised 


computer  programs  intended  to  help  designers  assess  the  interactions  among  design 
variables  in  the  form  of  an  "interaction  matrix"  and  to  solve  for  minimally-interacting 
groups  of  such  variables  (3).  Lewis,  Samuel  and  Field  (4)  and  Luckman  (5)  have 
explored  this  general  type  of  approach  by  means  of  examples. 

At  this  point,  I  am  unaware  of  any  data  that  can  be  used  to  test  the  proposal 
that  a  reduction  in  problem-solving  interdependence  among  innovation-related  tasks 
will  be  associated  with  an  increase  in  innovation  project  efficiency.  However,  one 
may  get  an  intuitive  feeling  for  the  plausibility  of  this  idea  by  considering  two  very 
simple  and  schematic  examples.  Each  specifies  an  innovation  project  and  then 
suggests  two  alternative  ways  to  divide  the  project  into  two  component  tasks.  These 
altematives  differ  with  respect  to  problem-solving  interdependence  between  tasks  and 
as  a  consequence  I  suggest  -  also  appear  to  differ  with  respect  to  the  efficiency  with 
which  they  can  be  carried  out. 

First,  consider  how  one  might  partition  the  project  of  designing  an  airplane. 
In  fact,  of  course,  such  a  project  would  be  partitioned  into  thousands  of  tasks.  But, 
for  present  purposes  let  us  assume  that  it  will  be  partitioned  into  only  two  tasks,  each 
to  be  undertaken  by  a  different  fimi.  The  two  altemative  partitionings  I  propose  we 
compare: 

-  "Fimi  X  is  responsible  for  the  design  of  the  aircraft  body  and  firm  Y  is 
responsible  for  the  design  of  the  engine, 

and: 

-  "Fimi  X  is  responsible  for  designing  the  front  half  of  the  aircraft  body  and 
engine,  and  fimi  Y  is  responsible  for  the  back  half  of  each. 

Taken  together,  each  of  these  proposed  partitionings  has  the  same  project 
outcome  -  a  complete  aircraft  design.  But  the  two  differ  greatly  with  respect  to  the 
interdependence  of  the  two  tasks  specified.  Tlie  second  altemative  would  require  a 


much  higher  level  of  problem-solving  between  the  two  tasks.  For  example,  many 
design  decisions  affecting  the  shape  of  the  "front  half'  of  an  aircraft  body  could  not 
be  made  witliout  forcing  related  changes  on  the  designers  of  the  back  of  the  body 
and  vice  versa:  The  two  halves  cannot  be  considered  independently  with  respect  to 
aerodynamics.  In  contrast,  the  detailed  design  of  a  complete  aircraft  engine  is  much 
less  dependent  on  the  detailed  design  of  a  complete  aircraft  body.  As  a  direct 
consequence,  I  suggest,  engineers  would  think  the  former  partitioning  far  more 
efficient  than  the  latter.  Indeed,  faced  with  the  latter  proposed  division,  experts 
would  be  likely  to  throw  up  tlieir  hands  and  say,  "It  can't  be  done  that  way". 

As  a  second  example,  consider  how  one  might  partition  the  project  of 
designing  the  interiors  of  two  rooms  between  two  interior  decorators.  One  might 
assign  each  room  to  each  decorator;  one  might  assign  one-half  of  each  room  to  each. 
Again,  the  same  work  is  to  be  accomplished  in  each  instance.  Only  the  way  it  is 
divided  up  has  been  changed. 

In  this  example,  the  idea  of  two  interior  decorators  each  designing  one-half  of 
a  room  probably  seems  absurdly  inefficient  to  the  reader.  And  again,  I  propose  that 
this  is  because  of  the  need  for  between-task  problem  solving  that  is  inferred.  That 
is,  it  seems  reasonable  that  a  solution  devised  by  one  decorator  and  implemented  on 
one  side  of  a  room  must  cause  the  second  artist  to  make  responsive  adaptations  on 
the  other  side  of  the  room  if  a  satisfactory'  total  design  is  to  result.  We  can  see 

that  it  is  the  need  for  problem-solving  across  tasks  that  makes  these  partitionings 
seem  inefficient  by  slightly  changing  the  nature  of  the  task  in  this  second  example. 
Suppose  that  problem-solving  is  clearly  not  involved  in  the  room-design  project. 
For  example,  suppose  that  the  physical  task  is  the  same  -  two  interior  decorators  are 
each  assigned  one -half  of  a  room  to  design  -  but  suppose  that  the  decorators  work 
for  a  hotel  chain  and  proceed  according  to  a  strict  formula.  In  that  case,  asking  each 
decorator  to  design  half  a  room  might  be  a  perfectly  acceptable,  and  possibly  even 
efficient,  partitioning  of  the  task.  For  example,  one  decorator  could  specialize  in 
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applying  the  formula  to  window  decorations,  and  one  could  specialize  in  applying  it 
to  room  furnishings. 


3.0:  Understanding  and  Managing  Task  Partitioning 

In  order  to  understand  and  manage  task  partitioning  we  must  be  able  to:  (1) 
predict  which  tasks  are  likely  to  be  the  source  of  important  new  information;  (2) 
predict  which  other  tasks  in  the  network  are  likely  to  be  affected  by  that  new 
infomiation;  (3)  use  such  predictions  to  understand  and  manage  tlie  impact  of  change 
during  the  course  of  an  innovation  project. 

For  "very  novel"  projects,  an  ability  to  predict  the  source  and  pattem  of 
problem-solving  is  equivalent  to  saying  that  we  be  able  to  predict  the  unexpected  - 
not  a  very  promising  prospect.  However,  it  is  quite  reasonable  to  expect  to  be  able 
to  predict  these  things  in  the  instance  of  less  novel  innovation  projects.    And, 
happily,  this  more  modest  capability  appears  to  be  all  tliat  is  needed  in  most  instances 
because  most  innovation  projects  in  most  fimis  do  not  in  fact  involve  great  novelty. 
Thus,  computer  companies  specialize  in  repeatedly  developing  the  next  new  model 
computer,  and  auto  firms  specialize  in  repeatedly  developing  the  next  new  auto 
model.    Under  such  conditions,  innovators  learn  much  from  prior  projects  as  to 
areas  where  change  is  likely  to  be  needed  during  the  course  of  a  future,  similar 
innovation  project.  For  example,  an  engineer  experienced  in  auto  design  work  can 
look  at  specifications  for  a  new  model  car  and  easily  predict  tlie  areas  where  the  most 
difficult  design  problems  are  likely  to  be  encountered  during  the  course  of  tlie 
project. 

The  way  tliat  changes  to  a  given  task  are  likely  to  propagate  across  a  task 
network  can  also  often  be  predicted  by  project  personnel  who  have  experience  with 
similar  projects.  TTius,  changes  in  the  design  of  some  components  of  an  auto  engine 
can  be  expected,  with  a  near-certainty,  to  require  changes  in  other  design  tasks, 


because  the  tasks  are  predictably  interdependent  with  respect  to  problem-solving. 
For  example,  problem-solving  with  respect  to  the  shape  of  the  top  of  a  piston  in  an 
auto  engine  is  predictably  very  interdependent  with  the  task  of  problem-solving  with 
respect  to  the  shape  of  a  cavity  in  the  cylinder  head  of  an  auto  engine:  The  two 
shapes  combine  to  form  the  overall  shape  of  an  auto  engine  combustion  chamber, 
and  the  shape  of  the  combustion  chamber  is  an  important  variable  in  engine  design. 
In  contrast,  the  likelihood  that  changes  to  either  or  both  of  these  components  will 
require  changes  in  the  tasks  of  designing  many  other  parts  of  the  auto  engine  - 
ranging  from  alternator  to  engine  mounts  -  will  be  seen  as  predictably  very  remote  by 
those  who  understand  auto  encine  design. 

Suppose,  then,  that  one  can  predict  the  "areas"  where  new  information  will  be 
developed  during  the  course  of  an  innovation  project.  And  suppose  also  that  one  can 
predict  something  about  the  location  of  related  changes  Ukely  to  be  required  or  made 
desirable  due  to  such  new  information.  How  can  one  use  this  information  to 
improve  innovation  project  management?  To  this  point  I  have  suggested  that  one 
might  relocate  task  partitions  to  minimize  the  need  for  problem-solving  across  task 
boundaries.  Let  me  now  suggest  the  additional,  complementary  strategy  of  reducing 
the  cost  of  engaging  in  problem-solving  across  task  boundaries.  I  will  briefly 
elaborate  on  each  of  tliese  possibilities  next. 

Improve  Partitioning 

The  first  approach,  minimizing  problem-solving  across  task  boundaries  by 
"properly"  locating  initial  task  boundaries,  requires  the  ability  to  predict  the  likely 
source  and  pattern  of  problem-solving  activity  in  an  innovation  project  discussed 
above.  Ideally,  tlie  partitions  initially  established  will  be  located  so  that  the 
development  of  an  optimal  solution  via  problem-solving  within  the  boundaries  of 
each  task  specified  will  also  provide  an  optimal  solution  for  the  overall  project. 

Currently,  I  am  not  aware  of  any  methods  that  can  enhance  practitioner  insight 
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with  respect  to  identifying  likely  areas  and  patterns  of  change  in  an  innovation 
project.  Tools  do  exist,  however,  that  can  help  managers  to  record  and  to  think 
through  tiie  implications  of  their  insights.  As  was  mentioned  earlier,  several  authors 
have  developed  interaction-matrix  approaches  to  aid  in  the  management  of  this 
problem  in  the  instance  of  engineering  design.  A  version  of  such  models  developed 
and  used  by  practitioners  called  the  House  of  Quality  has  also  recently  been  reported 
on  (6).  Among  other  things,  this  model  encourages  project  participants  to  list 
features  of  a  product  being  developed  that  are  interdependent  in  engineering  terms. 

For  example,  the  method  encourages  project  participants  to  note  that:  'The 
better  an  auto  door  is  at  tightly  sealing  out  noise  and  dirt  (a  desirable  characteristic), 
the  harder  it  is  to  close  (an  undesirable  characteristic)  given  that  conventional  sealing 
technology  is  applied'.  Such  infomiation  can  then  be  used  to  improve  task 
partitioning.  Thus,  if  project  specifications  require  improvements  in  door  closing  or 
door  sealing,  the  presence  of  the  interaction  with  respect  to  these  two  matters 
suggests  that  arranging  task  partitions  so  that  botli  are  included  in  a  single  "improve 
door  closing  and  door  sealing"  task  would  reduce  task  problem-solving 
interdependence  in  this  instance. 

Also,  task  network  modeling  tools  used  by  innovation  project  managers  such 
as  PERT,  GERT  and  VERT  can  be  useful.  They  require  data  regarding  project  task 
content  and  the  interactions  between  project  tasks  as  an  input.  But,  given  these,  they 
can  then  help  practitioners  think  through  the  implications  of  their  insights  and 
predictions  for  task  network  behavior.  (7) 

Ease  Cross-Boundary  Prohlcm-Soh'ing 

■  -  ~  »' ^ 

A  second  approach  to  managing  task  problem-solving  interdependence 
involves  reducing  the  cost  of  engaging  in  problem-solving  across  task  boundaries. 
This  approach  is  complementary  to  the  one  discussed  above:  It  regards  existing  task 
partitions  as  given,  and  seeks  ways  to  minimize  the  costs  of  any  associated 
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cross-boundary  problem-solving.  Therefore,  both  approaches  can  be  applied 
simultaneously  when  attempting  to  manage  the  effects  of  task  problem-solving 
interdependence. 

There  has  long  been  a  literature  in  the  field  of  organizational  behavior  that 
explores  ways  to  pass  information  across  group  boundaries,  or  to  integrate  groups 
divided  by  a  boundary.  Therefore  we  are  currently  better  provided  with  tools  for 
lowering  the  cost  of  problem-solving  across  boundaries  than  we  are  with  tools  for 
improving  initial  project  task  partitioning.  Naturally-occurring  mechanisms  to  this 
end  such  as  the  "gatekeeper"  who  takes  on  the  role  of  passing  infomiation  between 
groups  have  been  described. (8)  Also,  various  inventions  developed  specifically  to 
accomplish  boundary  spanning  such  as  the  "integrating  group"  (9)  have  been 
described  by  specialists  and  been  applied  in  the  field. 

One  could  address  such  tools  to  our  present  problem  by  first  predicting  where 
high  interaction  between  tasks  will  be  required,  and/or  monitoring  task  activities  to 
identify  such  needs  as  they  arise.  Then,  special  efforts  could  be  made  to  ease 
communication  across  the  relevant  task  boundaries.  Thus,  in  this  second  approach 
one  might  keep  the  door  closing  and  door  sealing  activities  described  earlier  as  two 
independent  tasks.  But,  upon  noting  the  problem-solving  interdependence  between 
them,  one  could  take  steps  to  facilitate  problem-solving  interaction  across  that 
particular  boundar)'. 

There  is  also  a  more  recent  literature  reporting  on  tlie  Japanese  industrial 
experience  in  this  matter.  Here,  the  emphasis  appears  to  be  less  on  specific 
mechanisms  intended  to  span  a  particular  boundary  for  a  particular  end,  and  more  on 
organizational  designs  that  encourage  a  general  high  level  of  communication  and  a 
reduction  of  barriers  to  communication  and  joint  problem-solving  between  all  project 
tasks. 

Thus,  Imai  (10)  reports  that  five  very  successful  product  development  projects 
by  Japanese  fimis  used  multifunctional  development  teams  of  30  or  less  people  to 
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develop  relatively  complex  products  having  a  significant  degree  of  novelty  in  their 
fields.  (Honda,  the  'City'  car;  Fuji-Xerox,  the  FX-35(X)  copier;  Canon,  the  'Sure 
Shot'  camera;  NEC,  the  PC  8000  personal  computer;  Epson,  the  MP-80  dot  matrix 
computer  printer). 

Imai  points  out  many  ways  in  which  these  teams  were  designed  to  maximize 
within-team  information  flow  and  minimize  task  boundaries,  and  contrasts  this  with 
US  product  development  practice.  Thus,  he  points  out  that  project  phases  such  as 
product  concept,  feasibility,  definition  and  design  -  often  sharply  demarked  in  US 
practice  with  progress  reviews  and  approvals  -  were  much  less  defined  and 
overlapped  more  heavily  in  the  practice  of  the  Japanese  teams.  He  notes  that: 

"The  loose  coupling  of  [project]  phases  also  makes  the  division  of 
labor,  in  the  strict  sense  of  the  word,  ineffective.  Division  of  labor  works 
well  in  a  [US  style]  system  where  the  tasks  to  be  accomplished  in  each  phase 
are  clearly  delineated  and  defined.  Each  project  member  knows  his  or  her 
responsibility,  seeks  depth  of  knowledge  in  a  speciahzed  area,  and  is 
evaluated  on  an  individual  basis.  But  such  segmentalism  ...  works  against  the 
grain  of  a  loosely  coupled  system  [such  as  that  observed  in  the  Japanese 
development  projects].  Here,  the  norm  is  to  reach  out  across  functional 
boundaries  as  well  as  across  different  phases.  Project  members  are  expected 
to  interact  with  each  other  extensively,  to  share  everything  from  risk,  responsi- 
bility [and]  information  to  decision-making,  and  to  acquire  breadth  of 
knowledge  and  skills.  (1 1) 

Under  such  conditions,  barriers  between  many  project  tasks  may  indeed  be  very 
low  and  flexible,  thus  eliminating  the  need  to  make  special  accommodation  for  those 
tasks  having  high  interdependence  with  respect  to  problem-solving. 


4.0:  Practical  Importance 

Is  management  of  the  problem-solving  interdependence  of  tasks  a  matter  of 
any  practical  importance  to  innovators?  I  think  so,  and  will  illustrate  tlie  possibility 
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anecdotally  by  looking  at  two  areas  in  the  innovation  process  that  are  known  to  be 
problematic  through  the  lens  of  task  partitioning.  The  first  of  these  is  commonly 
called  the  "marketing-R&D"  or  "marketing  research  -  product  design"  interface  in  the 
innovation  process  literature.  The  second  is  typically  referred  to  as  the  "product 
design  -  process  design"  or  "design-build"  interface  in  that  hterature.  These  two 
interfaces  are  the  boundaries  between  the  three  tasks  of  marketing  research,  product 
design  and  process  design.  All  three  tasks  are  typically  carried  out  (in  series  or  with 
some  time  overlap)  during  the  course  of  an  innovation  project.  In  what  follows,  I 
will  first  consider  tlie  "design-build"  interface  in  some  detail.  Then  I  will  more 
briefly  incorporate  the  marketing-R&D  interface  into  the  discussion. 

4.1:  The  Product  Desien  -  Process  Design  Interface 

Traditionally,  the  interface  between  product  design  and  process  design  has 
been  a  source  of  difficulty  in  the  progress  of  an  innovation  project.  Traditionally, 
also,  this  difficulty  has  been  framed  as  the  problem  of  transferring  information 
smoothly  and  completely  from  the  former  to  the  latter.(12)  More  recently,  however, 
the  underlying  assumption  of  a  one-way  flow  from  product  design  to  process  design 
has  begun  to  be  seen  as  a  problem  in  itself.  In  essence,  researchers  and  practitioners 
now  better  appreciate  that  the  product  and  process  design  tasks  can  interact  in  a  way 
that  requires  two-way  communication  and  joint  problem-solving  between  the  groups 
engaged  in  these.  That  is,  the  way  you  design  a  product  has  implications  for  process 
design  -  and  vice  versa. 

For  example,  a  product  designer  may  initially  design  a  component  part  that  is 
very  difficult  to  manufacture  -  despite  instructions  and  good  intentions  -  because  he 
does  not  understand  manufacturing  processes  well.  He  will  typically  be  able  to 
change  his  design  to  resolve  the  problem  -  if  told  of  the  difficulty  in  a  timely  manner. 
But  if  product  designers  only  provide  information  to  process  designers  at  the 
completion  of  product  design,  there  will  obviously  be  no  opportunity  for  process 
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designers  to  provide  the  needed  data  during  the  time  when  the  design  work  is  still 

underway  and  changes  could  be  relatively  easily  accommodated. 

Two  empirical  studies  I  am  aware  of  have  examined  the  design-build 

interface,  and  have  shown  that  an  increase  in  interaction  across  this  boundary  is 

associated  with  increased  project  efficiency.  Thus,  authors  of  a  study  of  the  matter 

in  the  commercial,  power,  light  industrial  and  heavy  industrial  segments  of  the 

constmction  industry  found  that: 

"...  a  construction  specialist  [building  constructor],  working  with  the 
engineering  team  [building  designers]  as  the  project  is  defined  and  designed, 
can  cut  costs  by  10  to  20  times  the  added  cost  of  extra  personnel.  On  a  $30 
million  project,  an  extensive  constructability  program  may  cost  $50,000,  but 
can  bring  savings  of  $1  million.  Costs  and  schedules  are  trimmed  by: 

-  Arranging  the  optimum  preparation  of  both  engineering  details  and  the 
sequence  in  which  tliey  are  prepared  so  as  to  avoid  delays  in  construction  on 
the  site. 

-  Taking  advantage  of  the  latest  construction  technology  as  part  of  the  design. 

-  Developing  work-simplifying  methods  and  minimizing  labor-intensive 
design."(13) 

Similarly,  Clark  et  al  (14),  in  a  recent  comparison  of  aspects  of  the  European, 
Japanese,  and  US  auto  industries,  provide  a  detailed  case  study  of  how  information 
was  passed  between  designers  of  the  sheet-metal  parts  that  make  up  the  surface  of  an 
automobile,  and  the  designers  of  the  dies  used  to  produce  these  parts.  In  the 
Japanese  firms,  they  found,  the  work  of  parts  designers  and  dies  designers  had  a 
larger  overlap  with  respect  to  time  than  did  US  and  European  firms.  They  also 
found  that  Japanese  parts  designers  typically  passed  preliminar}'  infomiation  more 
frequently  to  die  designers  regarding  the  planned  shape  of  parts  as  work  progressed. (15) 
As  a  consequence,  they  suggest,  die  designers  in  the  Japanese  fimis  were  in  a  better 
position  to  begin  the  design  of  dies  while  some  areas  of  shape  were  still  uncertain, 
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and  to  suggest  changes  to  part  designers  in  a  timely  fashion  that  would  reduce  the 
cost,  complexity  or  number  of  dies  required  to  make  the  part. 

On  the  basis  of  studies  such  as  these,  plus  anecdotal  reports  of  good  results  in 
various  firms  with  "design-build"  teams,  practitioners  and  researchers  are  now 
moving  to  the  view  that  closer  interaction  between  product  and  process  design  is  in 
general  beneficial.  However,  if  we  view  this  problem  through  the  lens  developed  in 
this  paper  -  that  one  wants  to  partition  tasks  so  as  to  minimize  the  need  for 
problem-solving  across  task  boundaries  and/or  build  bridges  between  tasks 
anticipated  to  require  high  problem-solving  interaction  -  then  we  can  advance  the 
discussion  a  step  further,  in  my  view. 

I  propose  that  the  level  of  benefit  obtained  from  bridging  or  eliminating  the 
task  boundary  between  product  design  and  process  design  will  differ  as  a  function  of 
the  particular  part  and  process  at  issue.  This  is  because,  as  discussed  earlier,  the 
need  for  problem-solving  across  such  a  boundary  can  vary  depending  on  the 
particular  part  and  process  involved,  and  depending  upon  the  specifications  set  for 
task  outcomes. 

Thus,  in  the  case  study  by  Clark  et  al  mentioned  above,  the  design  of  parts 
and  of  the  dies  used  to  produce  them  are  clearly  very  interdependent  design  tasks, 
and  it  therefore  seems  reasonable  that  the  bridging  or  elimination  of  the  boundary 
between  these  two  tasks  would  improve  innovation  process  efficiency  and 
effectiveness. 

On  the  other  hand,  I  would  suspect  that  one  would  not  typically  get  a  similar 
benefit  by  bridging  or  eliminating  the  task  barrier  between  product  design  and 
process  design  in  the  instance  of  "middle-of-the-road"  printed  circuits.  This  is 
because  standard  printed  circuit  manufacturing  technology  is  capable  of  producing 
any  such  ordinar}'  circuit  without  any  process  adjustments  being  needed  or  useful. 
That  is,  there  will  not  usually  be  a  need  for  joint  problem-solving  -  or  two-way 
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communication  -  between  these  two  tasks.  (Those  unfamiHar  with  printed  circuit 
technology  can  think  of  book  printing  as  a  useful  substitute  example.  Book  authors 
typically  do  not  have  to  write  their  books  with  the  needs  of  the  printer  in  mind, 
because  the  ordinary  printing  process  does  not  have  to  be  adapted  to  the  particular 
words  chosen  by  an  author.  In  contrast,  a  graphics  designer  trying  to  do  something 
that  pushes  the  limits  of  existing  printing  processes  might  well  find  joint 
problem-solving  with  the  printer  to  be  very  valuable.) 

The  need  to  make  choices  with  respect  to  where  one  will  ehminate  task 
boundaries  and/or  increase  interaction  across  them  can  be  illustrated  by  reference  to 
the  practice  of  some  auto  manufacturers  of  sometimes  assigning  the  detailed  design 
work  for  auto  components  they  will  purchase  to  the  suppHer  firms  that  will 
manufacture  them. (16) 


Component  B 
Manufacturer: 
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Figure  2:  Shifting  the  detailed  design  of  one  product  component  (Component  B) 
from  the  fimi  designing  tlie  product  to  the  fimi  that  will  manufacture  it  improves  the 
design-build  linkage  for  Component  B  -  but  weakens  the  design  linkage  between 
Component  A  and  Component  B. 


As  is  suggested  in  Figure  2,  a  shift  of  the  detailed  design  of  automobile 
component  A  from  the  firm  that  designs  the  overall  automobile  to  the  fimis  that 
builds  the  component  probably  increases  the  barriers  between  the  design  of 
component  A  and  component  B,  while  decreasing  the  barrier  between  product  design 
and  process  design  for  these  components.  After  all,  the  shift  involves  a  shift  in  the 
physical  and  organizational  location  of  the  component  design  work  from  a  close(r) 
proximity  with  other  design  tasks,  and  to  a  closer  proximity  with  process  design 
tasks.  And,  as  mentioned  earlier,  Allen  (1)  has  shown  that  both  physical  and 
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organizational  distance  appear  to  represent  significant  barriers  to  technical 
communication. 

Clark  et  al  have  found  the  assignment  of  greater  amounts  of  detailed 
component  design  work  to  component  suppliers  to  be  strongly  associated  with  a 
reduction  in  the  time  required  to  develop  a  new  model  car.  Indeed,  they  estimate  that 
"...bringing  an  additional  twenty  percent  of  the  engineering  effort  in-house  and 
inside  the  project  [that  is,  assigning  less  of  the  detailed  component  design  work  to 
the  component  supplierl  would  add  eight  months  to  project  lead  time."(17). 

In  hne  with  arguments  made  earher,  I  suggest  that  further  examination  will 
show  that  the  effect  of  this  shift  is  positive  only  for  those  components  where  there  is 
less  benefit  obtainable  from  problem-solving  interaction  between  particular 
component  design  tasks  than  between  the  tasks  of  product  design  and  process 
design.  For  example,  I  suspect  that  shifting  the  detailed  design  of  an  electrical 
alternator  (generator)  to  be  used  in  a  new  model  car  from  the  auto  design  firm  to  the 
component  manufacturer  would  result  in  a  net  improvement  in  efficiency:  there  is 
little  design  trade-off  between  generator  design  and  the  design  of  other  components. 

On  the  other  hand,  if  the  component  in  question  is  the  plastic  ducting  used  to 
distribute  hot  and  cold  air  to  a  car's  interior,  I  would  expect  the  reverse  to  be  true. 
Such  ducting  is  bulky,  and  must  be  laid  out  with  an  intimate  knowledge  of  the 
location  and  size  of  many  other  auto  components  if  it  is  to  be  fitted  within  the  car 
properly.  To  carry  out  this  design  process  efficiently,  it  seems  to  me,  there  would 
be  a  need  for  creative,  interactive  problem-solving  involving  the  designers  of  the  car 
as  a  whole  and  the  designers  of  the  air  ducting  components.  Thus,  the  gain  from 
reducing  the  barriers  to  such  interaction  by  keeping  both  design  tasks  within  the  auto 
manufacturer  seems  to  me  likely  to  outweigh  any  advantage  to  be  gained  from 
shiftin2  detailed  desicn  to  the  manufacturer  in  this  instance. 
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4.2:  The  Marketing  Research  -  Product  Design  Interface 

The  interface  or  boundary  between  the  marketing-R&D  interface  has  long 
been  judged  to  be  a  source  of  problems  with  respect  to  the  commercial  success  of 
innovation  projects  because:  Most  new  products  developed  fail  in  the  marketplace 
(18);  accurate  understanding  of  user  need  has  been  shown  key  to  innovation  project 
success  (19);  engineers  and  marketers  are  often  unhappy  with  the  quality  of  the 
infomiation  regarding  user  need  transmitted  across  the  marketing-R&D  interface 
(20). 

As  was  the  case  with  the  design-build  interface,  the  "interface  problem"  has 
been  traditionally  seen  as  one  of  smooth  and  accurate  transfer  of  "need"  information 
from  marketing  to  product  designers.  Today,  however,  improved  two-way 
communication  across  this  interface  is  now  clearly  identified  as  a  likely  way  to 
improve  perfomiance  at  this  interface. (21)  However,  as  in  the  case  of  tlie 
design-build  interface,  I  suggest  that  the  benefit  realizable  from  repartitioning  tasks 
to  eliminate  the  boundar)'  between  marketing  research  and  product  design,  or  taking 
steps  to  ease  problem-solving  across  that  boundary,  will  depend  on  the  amount  of 
joint  problem-solving  required  acro'.s  the  interface  in  any  particular  instance. 

Thus,  a  single  one-way  message  from  marketing  to  product  design  may 
suffice  if  the  need  infomiation  is  unambiguous,  and  if  the  designers  can 
accommodate  the  request  without  compromising  other  product  characteristics. 
E.g.,  "The  customer  wants  this  software  to  interface  with  the  XYZ  printer."  On  the 
other  hand,  joint  problem-solving  between  marketing  researchers,  customers  and 
product  designers  will  clearly  be  valuable  when,  for  example,  data  on  new  product 
needs  provided  by  marketing  research  to  engineering  have  consequences  or  offer 
opportunities  that  are  not  initially  visible  to  all  these  parties.  E.g.  "Are  you  aware 
that  adding  memory  to  the  computer  as  you  request  will  make  it  slower?"  Or,  "Do 
you  realize  that  if  we  add  extra  memory  we  can  also  add  feature  X  at  no  cost?" 
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5.0:  Discussion  and  Suggestions  for  Further  Research 

In  this  paper  I  have  proposed  that  the  level  of  problem-solving 
interdependence  between  tasks  is  a  function  of  choices  made  with  respect  to  task 
partitioning.  I  have  also  suggested  that  such  choices  can  be  managed,  and  that  doing 
so  may  have  an  important  impact  on  innovation  process  efficiency.    It  seems  to  me 
that  these  proposals  are  worth  exploring  further  from  the  point  of  view  of  both 
innovation  process  research  and  innovation  practice. 

Innovation  task  partitioning  is  potentially  a  very  interesting  topic  in  the  field  of 
innovation  process  research  because  it  bears  directly  on  the  matter  of  how  innovation 
can  be  most  efficiently  distributed  within  and  among  fimis.  Findings  related  to 
partitioning  can  therefore  serve  as  a  useful  input  to  research  on  topics  ranging  from 
specialization  to  vertical  integration  to  the  role  of  suppliers  in  the  innovation  process. 

In  such  research,  the  conditional  nature  of  improvements  to  innovation 
process  efficiency  as  a  result  of  changes  in  task  partitioning  will  become  evident  and 
important.  That  is,  decisions  regarding  partitioning  influence  far  more  than  problem- 
solving  efficiency.  Tliey  also  have  an  impact  on  matters  ranging  from  the  efficient 
utilization  of  specialized  resources,  to  the  ability  of  a  fimi  to  protect  its  innovation- 
related  advantages  in  the  marketplace.  Sometimes  partitioning  from  the  point  of 
view  of  minimizing  problem-solving  interdependence  among  tasks  will  have  positive 
impacts  on  these  related  matters,  but  sometimes  a  trade-off  of  benefits  will  be 
required.  (E.g.,  "We  would  gain  efficiency  if  the  manufacturer  of  component  X 
worked  with  our  designers  at  an  early  stage,  but  tliis  strategy  would  also  increase 
our  risk  that  news  of  our  new  product  might  leak  early  and  reduce  our  profits.") 

An  improved  understanding  of  innovation  task  partitioning  will  be  important 
to  innovation  managers  if  and  as  it  can  have  an  important  impact  on  innovation 
project  efficiency  and  effectiveness.  The  magnitude  of  this  effect  needs  to  be 
empirically  explored.  As  an  initial  step,  it  might  be  reasonable  to  attempt  to  view  the 
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efficiency  effects  of  innovation  project  task  partitioning  in  isolation.  One  might  be 
able  to  do  this  experimentally  by,  for  example,  systematically  varying  the  way  a 
given  software  development  project  is  divided  into  modules  (tasks)  and  observing 
the  effect  of  these  variations  on  project  efficiency. 

Next,  it  might  be  reasonable  to  explore  the  possibility  of  managing  innovation 
task  partitioning  in  practice  to  achieve  efficiency  gains  in  innovation  project  work. 
For  example,  one  might  select  a  sample  of  innovation  projects  for  study,  list  the 
major  tasks  associated  with  each,  and  then  ask  project  participants  to:  (1)  rank  the 
degree  of  problem-solving  interaction  required  among  different  hsted  tasks  and,  (2) 
rank  the  ease  of  accomplishing  such  problem-solving  among  these  same  tasks.  A 
large  mismatch  between  the  answers  to  the  two  questions  might  indicate  that 
practically  useful  task  partitioning  changes  could  be  made,  and  would  also  suggest 
where  these  might  lie. 

If  improvements  to  innovation  task  partitioning  can  yield  major  benefits  to 
firms,  we  then  have  much  to  learn  about  managing  it.  Firms  I  have  interviewed  to 
date  appear  not  to  think  about  task  problem-solving  interdependence  as  an  input  to 
partitioning  decisions  at  all.  Instead,  some  appear  to  make  such  decisions  primarily 
on  the  basis  of  assumed  economies  of  specialization  (e.g.:  "AH  electrical  design 
work  win  be  done  by  group  A";  "All  marketing  research  studies  will  be  done  by 
group  M").  Other  firms  appear  to  simply  follow  some  traditional  pattem  of 
innovation  task  partitioning  without  analysis.  (E.g.:  "We  have  always  designed 
aircraft  bodies  by  dividing  tliem  into  a  series  of  cylindrical  sections  and  assigning 
each  section  to  a  different  task  group.  No  one  now  at  the  company  has  thought 
about  why  we  do  this  or  whether  it  currently  makes  sense  from  any  point  of  view.  It 
is  just  the  way  we  do  it.") 

Given  this  situation,  it  v^'ould  seem  reasonable  to  start  research  into  the 
effective  management  of  innovation  task  partitioning  with  basic  issues  such  as: 
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When  should  one  attempt  to  specify  task  partitions  at  the  start  of  a  project,  and  when 
should  one  strive  for  the  capability  for  flexible  mid-project  changes?;  What 
partitioning  decisions  will  be  best  made  "bottoms-up"  by  lower-level  project 
personnel  (who  may  currently  be  making  mid-project  partitioning  adjustments 
informally  and  covertly  in  any  case  (22)),  and  which  should  be  made  "top-down"? 

I  look  forward  to  studying  innovation  task  partitioning  further,  and  ver}'  much 
hope  that  otliers  might  also  find  the  area  interesting  enough  to  explore. 
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